Turning to FIG. 1, an example of a conventional USB system 100 can be seen. This system 100 is an example of a system that is compliant with the USB Battery Charging Specification, Revision 1.2 plus Errata, dated Oct. 12, 2011 (which is incorporated herein by reference for all purposes). In this example, there are two USB devices (e.g., notebook computers) that are coupled to one another through a cable. This cable includes a power bus and a data bus. The power bus generally comprises a power conductor or wire VBUS (which can also be referred to as the VBUS conductor), a shield conductor SH (which can function as a ground conductor or wire), while the data bus can generally comprise data lines D[1] to D[N]. In this arrangement, functional circuits 108-1 and 108-2 can communicate data with one another, and power can be delivered over the power conductor VBUS and shield conductor SH between power supplied 106-1 and 106-2 (with capacitors C1-1 and C1-2 being coupled between the conductors VBUS and SH). Typically, these USB devices (e.g., 102-1 and 102-2) can operate only as single-role devices so they operate as consumers (i.e., having the capability to sink power from the power conductor VBUS) or providers (i.e., having the capability to source power over the power conductor VBUS).
Whereas the BC1.2 device described in FIG. 1 and paragraph [003] communicates via the data lines to negotiate power provided, the USB Power Delivery specification defines signaling over the VBUS conductor to negotiate the power provided. In FIG. 5, the Controller 314 can transmit and receive signals over VBUS using frequency shift keying. As part of the functional circuit in the USB device 302 (See FIG. 5), there is a device policy manager and a policy engine (which can, for example be implemented as finite state machines) that can interact with one another, and an example of a source port policy engine state diagram can be seen in FIG. 2. At startup (in state 202), an initial starting state either on power up or after a Hard Reset (e.g., state 222) is set. On entry to this state 202, the policy engine resets the Protocol Layer and reset the CapsCounter (which is an counter used to count the number of Capabilities messages that convey a port's capabilities to source power including Dual-Role ports presently operating as a sink). Once the reset has completed the policy engine can transition to the Send Capabilities state 206.
On entry to the Discovery state 204 the policy engine performs the following tasks:                Initialize and run the SourceCapabilityTimer in order to trigger sending Capabilities If the SourceCapabilityTimer expires, no request is received from the partner device and the CapsCounter exceeds a maximum value nCapsCount, the policy engine can either enter the Disabled state 218 or the Hard Reset state 222.        
Following the Startup state 202, the policy engine can enter the send capabilities state 206. In particular, a capabilities change event from the device policy manager while in any state can trigger the policy engine to enter the Send Capabilities state 206. There are also transitions from the Soft Reset state (not shown) and Protocol Error state (not shown). On entry to the Send Capabilities state 206, the policy engine can request the present port capabilities from the device policy manager. The policy engine can then request the Protocol Layer to send a Capabilities message containing these capabilities and can initialize and run the SenderResponseTimer (which ensures that a message requesting a response is responded to within a bounded time) and increment the CapsCounter (if implemented). If a GoodCRC message (i.e., acknowledgement that the previous message was correctly received) is received then the policy engine stops the NoResponseTimer and resets the HardResetCounter to zero. It should also be noted that the HardResetCounter is reset to zero in this state and at power up; its value can be maintained during a Hard Reset. The policy engine can then transition to the Negotiate Capability state 208 when a Request message (i.e., a message requesting power) is received from an attached Sink Port. The policy engine can also transition to the Discovery state 204 when the Protocol Layer indicates that the message has not been sent and we are presently unattached. This is part of the Capabilities sending process whereby successful message sending indicates attachment to a Sink Port. The policy engine can also transition to the Ready state when the SenderResponseTimer times out and the current power being used is still within the Source's present capabilities. No response from the Sink indicates it is content to continue to use the present power. The policy engine can also transition to the Hard Reset state 222 when the SenderResponseTimer times out and the present power being used is outside the Source's present capabilities. In this case a transition back to default power is required. When the NoResponseTimer times out and the HardResetCounter is greater than its maximum value (i.e., nHardResetCount), the policy engine can do one of the following:
Transition to the Discovery state 204.
Transition to the Disabled state 218.
It should be noted, too, that in either case the attached device is assumed to be unresponsive. The policy engine should operate as if the device is unattached until such time as a detach/reattach is detected.
Following the Send Capabilities state 206 and on entry to the Negotiate Capability state 208, the policy engine can ask the device policy manager to evaluate the Request from the attached Sink. The response from the device policy manager can be one of the following:
The Request can be met;
The Request cannot be met; or
The Request could be met later from the reserve.
The policy engine can transition to the Transition Supply state 210 when the Request can be met. The policy engine can transition to the Capability Response state 224 when the Request cannot be met or the Request can be met later from the reserve.
Following the Negotiate Capabilities state 208, the policy engine can be in the Transition Supply state 210 while the power supply is transitioning from one power to another. On entry to the Transition Supply state 210, the policy engine can initialize and run the SourceActivityTimer (i.e., timer used to maintain a minimum level of bus traffic), request the Protocol Layer to either send a GotoMin message (i.e., temporarily reallocate power to meet a short term requirement) if this was requested by the device policy manager or otherwise an Accept message and inform the device policy manager that it can transition the power supply to the Requested value of power. It should also be noted that if the power supply is currently operating at the requested power no change will be necessary. On exit from the Transition Supply state 210, the policy engine can request the Protocol Layer to send a PS_RDY message (i.e., indicates its power supply has reached the desired operating condition). The policy engine can transition to the Ready state 212 when the device policy manager informs the policy engine that the power supply is ready.
In the Ready state 212, the Source can operate at a stable power with no ongoing negotiation. It can respond to requests from the Sink, events from the device policy manager and can send out Ping messages (i.e., periodic message in the Ready state 212 when no other power negotiation or other messaging is taking place) to maintain the link. On entry to the Ready state 212, the policy engine can initialize and run the SourceActivityTimer. The policy engine can transition to the Transition supply state 210 when a GoToMin request is received from the device policy manager for the attached device to go to minimum power. The policy engine can transition to the Give Source Cap state 214 when a Get_Source_Cap message (i.e., request the Source Capabilities and Dual-Role capability) is received from the Sink. The policy engine can transition to the Get Sink Cap state 216 when the device policy manager asks for the Sink's capabilities. In the Disabled state 218, the Source supplies default power and is unresponsive to USB Power Delivery messaging. In order for the Source to transition to USB Power Delivery operation, a Hard Reset or some other form of reset is required. On entry to the Give Source Cap state 214 the policy engine can request the device policy manager for the current system capabilities. The policy engine can then request the Protocol Layer to send a Capabilities message containing these capabilities. The policy engine can transition to the Ready state 212 when the Capabilities message has been successfully sent. In the Get Sink Cap state 216, the policy engine, due to a request from the device policy manager, can request the Sink's capabilities from the attached Sink. On entry to the Get Sink Cap state 216 the policy engine can request the Protocol Layer to send a Get_Sink_Cap message in order to retrieve the Sink's capabilities. The policy engine can then start the SenderResponseTimer. On exit from the Get Sink Cap state 216 the policy engine can inform the device policy manager of the outcome (capabilities, response timeout or reject). The policy engine can transition to the Ready state 212 when a Sink Capabilities message is received or SenderResponseTimer times out.
The policy engine can enter the Capability Response state 224 if there is a Request received from the Sink that cannot be met based on the present capabilities. On entry to the Capability Response state 224 the policy engine can request the Protocol Layer to send one of the following:
Reject message—if the request cannot be met
Wait message—if the request could be met later from the reserve.
The policy engine can transition to the Ready state 212 when the Reject message or Wait message has been sent and the present value of power is still valid. The policy engine can transition to the Hard Reset state 222 when the Reject message or Wait message has been sent and the present value of power is not valid (i.e. the Sink had to request a new value so instead we will return to default operation).
The policy engine can transition from any state to the Hard Reset state 222 when the NoResponseTimer times out and the value the HardResetCounter is less than or equal to its maximum value (i.e., nHardResetCount) or the device policy manager requests a Hard Reset. On entry to the Hard Reset state 222 the policy engine can request the generation of Hard Reset signaling by the physical layer transceiver or PHY, initialize and run the NoResponseTimer and increment the HardResetCounter. It should also be noted that the NoResponseTimer can continue to run in every state until it is stopped or times out. The policy engine can transition to the Transition to default state 220 when the Hard Reset is complete.
The policy engine can transition from any state to the Transition to default state 220 when a Hard Reset signaling is detected. On entry to the Transition to default state 220, the policy engine can indicate to the device policy manager that the power supply can transition to default (e.g., 5V). The policy engine can then request a reset of the local hardware. The policy engine can transition to the Startup state 202 when the device policy manager indicates that the power supply has reached the default level.
In addition to the states shown in FIG. 2, the policy engine can also implement dead battery protocols. In FIG. 3, the state diagram for consumer/provider behavior for dead battery detection is shown. In FIG. 4, the state diagram for provider/consumer behavior for dead battery detection is shown.
Turning first to FIG. 3, the consumer/provider can transition from a consumer to a provider role. The consumer/provider begins operating as a consumer from state 206 of FIG. 3, requesting a Protocol Layer reset. On entering state 226, the value on the power conductor VBUS is determined. In this state the power on conductor VBUS may be zero or the default value and the power delivery status (i.e., whether there is a power delivery partner at the far end) is unknown. If the default value is present on the power conductor VBUS, the consumer/provider continues to operate as a consumer (i.e., sink port) and transitions to the wait for capabilities state 224. However, if the power conductor VBUS is not present (which typically means that the voltage on power conductor VBUS is about 0V). Power is provided to the power conductor VBUS in state 228. In this state 228, the policy engine instructs the device policy manager to apply a voltage vPDDeadBattery to the power conductor VBUS, where the voltage vPDDeadBattery is a default voltage in the range between about 3.75V and about 4.6V. The consumer/provider then waits for a preamble from its partner in state 230. The preamble indication is typically received by a physical transceiver or PHY. When the preamble is detected by the PHY of the consumer/provider, it transitions to the Transition to Default state 220 so as to operate as a provider or source port (which can allow for battery charging from the source port to the sink port).
In FIG. 4, the provider/consumer can transition from a provider to a consumer role. This begins from state 238 when the voltage vPDDeadBattery is applied to the power conductor VBUS. When this is accomplished, the provider/consumer checks its power in state 240 and decides whether it is willing and/or able to provide power. If it is willing to provide power, it moves to the “transition to default” state (state 220) as a source port (i.e., provider). Otherwise, the provider/consumer can indicate that it wants to be powered in state 242 by sending a preamble. When a default voltage is present on the power conductor VBUS, the provider/consumer enters state 224 to wait for capabilities as a consumer (i.e., sink port).
There are, however, some drawbacks with these dead battery procedures. Namely, using these protocols (as illustrated in FIGS. 3 and 4), the provider/consumer can assume the role as a sink port before a consumer/provider (which operates as the partner for the provider/consumer) is aware that it should assume the role as a source port. As a result, the role swap (i.e., from consumer or sink port to provider or source port) may not be achieved at all due to an error. The cause of this error is that the provider/consumer transitions to a sink port after it detects about 4.75V on the power conductor VBUS, but, because the back-powered voltage (vPDDeadBattery) may be as large as 4.6V, the provider/consumer could easily be mistaken while trying to distinguish between 4.6V and 4.75V. Additionally, there is some difficulty in accurately measuring voltages on the power conductor VBUS.
Therefore, there is a need for an improved dead battery protocol for use with the USB PD standard.